"Edward C." wrote:
> 
> Nathan Kopp wrote:
> >Actually, fade_distance and fade_color attenuation is computed in
> >compute_lighted_texture.  The code looks like this:
> <snip>
> 
> I assume you mean fade_power, not fade_colour.  Anyway, I never said it
> wasn't, I was just wondering why the FILTER and TRANSMIT values are
> attenuated along with the RGB components in compute_shadow_texture, but only
> the RGB components are attenuated in compute_shadow texture.  It is
> important to me since this behaviour breaks my patch (in some situations you
> get almost no colour in the shadow) so I have to disable it.
> 
> >Possible implementations:
> >1)  Add a new keyword fade_color and multiply the attenuation by it.
> >2)  Change fade_distance and fade_power to accept a vector (color) instead
> >    of a float.  (no need for any extra keywords)
> 
> I went with 1, I don't think I could have made 2 work the way I wanted, but
> I might do something like it to enable the user to specify different fade
> characteristics for each of the colour components.  I just need to take a
> little time to figure out how to accept both the old float arguement and my
> new vector arguement for fade_distance and fade_power, so as not to break
> old scenes.

Doesn't the POV parser automatically promote scalars to vectors in
Parse_Vector()?
So old scenes will not be broken as long as a vector with identical
components gives the same result as the current scheme.

Cheers, PoD.

Post a reply to this message